Space & Astronomy/Space and Astronomy (October 1993).iso/mac/TEXT/SPACEDIG/V11_1/V11_168.TXT

Internet Message Format | 1991-07-08 | 18KB

Return-path: <[e-mail]>
X-Andrew-Authenticated-as: 7997;andrew.cmu.edu;Ted Anderson
Received: from beak.andrew.cmu.edu via trymail for +dist+/afs/andrew.cmu.edu/usr11/tm2b/space/[e-mail] (->+dist+/afs/andrew.cmu.edu/usr11/tm2b/space/space.dl) (->ota+space.digests)
          ID </afs/andrew.cmu.edu/usr1/ota/Mailbox/0a1nRwO00VcJ0KAU4J>;
          Wed, 21 Mar 90 03:12:46 -0500 (EST)
Message-ID: <[e-mail]>
Reply-To: [e-mail]
From: [e-mail]
To: [e-mail]
Date: Wed, 21 Mar 90 03:12:09 -0500 (EST)
Subject: SPACE Digest V11 #168

SPACE Digest                                     Volume 11 : Issue 168

Today's Topics:
        Re: What was Challenger really up to?
           Death in Space (was Re: Shuttle Escapes)
         Re: Death in Space (was Re: Shuttle Escapes)
         Re: Another SR-71 comes to NASA Ames-Dryden
             Landsat-5 Emergency
       UoSAT-OSCAR-14 & UoSAT-OSCAR-15 Status Report  15-Mar-90
        Re: Resolving Power of Hubble Space Telescope
            Re: Challenger Report question
----------------------------------------------------------------------

Date: 20 Mar 90 00:19:26 GMT
From: swrinde!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo![e-mail]  (Henry Spencer)
Subject: Re: What was Challenger really up to?

In article <[e-mail]> [e-mail] (John H. Kim) writes:
>the sonar image that turned out to be the Challenger crew cabin.  It
>was just a bump on the bottom--there were no details that would let
>you say "yes, this is the crew cabin," it could just as easily have
>turned out to be a rock...

All the more so because the Cape has been a test range for decades, and
the bottom offshore is littered with man-made debris of all kinds.
There was at least one promising-looking false alarm that was really
a crashed helicopter.
--
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry [e-mail]

------------------------------

Date: 20 Mar 90 03:04:15 GMT
From: bfmny0![e-mail]  (Tom Neff)
Subject: Death in Space (was Re: Shuttle Escapes)

In article <[e-mail]> [e-mail] (Mary Shafer (OFV)) writes:
>It's my belief, however, that nothing is absolutely safe, particularly
>flight.  If informed people wish to assume the risk, that's their
>right and their decision.

Let them pay to train themselves for spaceflight, and this might be
true.  In the meantime, while the public foots the bills, I think we
should try to make our human components profoundly recoverable.  It's
nice that they're willing to die and all that, but we don't really pay
them to make such decisions.

>                            Nobody is forced to fly in the Shuttle,
>nobody is forced to fly in fighters or bombers or airliners.  We're
>all volunteers.  As long as we really understand the risk we're taking,
>what's the problem?

The problem is that killing people in space is a waste of time.  This is
not some game.  Every death in space is a horrific setback to the program.
Nobody, not even the crew members themselves, have the right to 'accept'
such a risk unquestioningly.  Their personal stake is only a small part of
the whole.

It's worth remembering that, almost without exception, past flight crew
deaths could have been avoided but for political expediency in one form
or another.  The roll of "space martyrs" is just that.  The myth of
"inevitable" crew losses needs re-examined.  The real "inevitability"
seems to be that every few years, political pressure will build to the
point where things get rushed, until something fatal is overlooked.

When I look at the crammed do-or-die schedule for NASA's Space Station,
my blood runs cold.  "My God, <contractor>, when do you want me to
launch?  2010?"
--
Perestroika: could   \O\     Tom Neff
 it happen here?      \O\    uunet.uu.net!bfmny0!tneff

------------------------------

Date: 20 Mar 90 05:24:47 GMT
From: skipper![e-mail]  (Mary Shafer (OFV))
Subject: Re: Death in Space (was Re: Shuttle Escapes)

But, no matter what you do, it will never be perfectly, 100% risk-free
to fly.  Or to drive, or to walk, or to do anything.

One of our pilots here died when he waited too long to eject from a
spinning aircraft.  He was wrong; he should have jumped out earlier.
He failed in his duty, IMO.

One of our engineers was walking his dog when a car driven by a kid
jumped the curb and hit him.  Only his leg was broken.  But he walks
his dog again, now.  Who know better than him the danger?

There's no way to make life perfectly safe; you can't get out of it alive.

You can't even predict every danger.  How can you guard against a hazard
you can't even conceive of?

I agree that the days of "kick the tires and light the fires" are gone,
but insisting on perfect safety is the single most reliable way of
killing an aerospace project.

I've been on both sides of the FRR (Flight Readiness Review) process
for a number of aeronautical projects.  Experienced engineers try to
think of everything that can go wrong.  But airplanes can still
surprise the best team.

I've had to sign a form, certifying that to the best of my knowledge
everything that we're going to do on a flight is safe.  I've never
seriously asked myself "What will I say to the AIB (Accident
Investigation Board)" because once one starts on that, the form will
never be signed, the flight will never be flown, and the research will
never be done.

But I have asked myself "Have I told everybody exactly what we're
going to do and what the _known_ risks are and are we agreed that
these risks are acceptable" and when I can answer that "yes" I sign
the form.  That also answers the question of what I'd say to the AIB.

I'm not talking about abstract theories here, I'm talking about test
pilots that I've known for decades.  Believe me, I _know_ exactly what
the consequences of a mistake on my part could mean.  The reminders
are all around me: Edwards AFB--killed in the XB-49, Lilly Ave--NASA
pilot killed in a crash, Love Rd--I _saw_ his burning F-4 auger into
the lakebed, with him in it.  But once I've done my best, like
everybody else on the team, it's time to go fly the airplane.

Insisting on perfect safety is for people who don't have the balls to
live in the real world.
--

Mary Shafer  [e-mail] or ames!skipper.dfrf.nasa.gov!shafer
         NASA Ames Dryden Flight Research Facility, Edwards, CA
                   Of course I don't speak for NASA

------------------------------

Date: 20 Mar 90 15:56:43 GMT
From: voder!dtg.nsc.com![e-mail]  (Alan Hepburn)
Subject: Re: Another SR-71 comes to NASA Ames-Dryden

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>In article <[e-mail]> [e-mail] (Mary Shafer (OFV)) writes:
>>And everybody troops back into the building on this beautiful spring
>>day, exhilerated by the flyby.
>
>Followed by the sound of several thousand people elsewhere on the net
>turning green with jealousy... :-[
>--


I second the emotion!  How about convincing the powers that be to do the
same thing up here by NASA-Ames?  Since my place of employment is just
a stone's throw from the blue cube (okay, a small stone thrown by a very
strong person!), I'm sure a low level pass like that would impress a lot
of people!  Just imagine the fun it would be to fly the SR71 around the
country, turning onto final at each local airport, firing the burners, and
blasting the windows out of the terminals!  (Sigh...)





--
-------------------------------------------------------------------------------
Alan Hepburn                            Omne ignotum pro magnifico
mail: [e-mail]             My opinions are just that: opinions
-------------------------------------------------------------------------------

------------------------------

Date: 20 Mar 90 18:25:59 GMT
From: cs.utexas.edu!usc!elroy.jpl.nasa.gov!jato!mars.jpl.nasa.gov![e-mail]  (Ron Baalke)
Subject: Landsat-5 Emergency



                       Landsat-5 Emergency

     The Landsat operations people had declared a Landsat-5 spacecraft
emergency and requested support from a JPL 34 meter tracking station in
Goldstone, California. The reason for the emergency was an apparent loss
of attitude control system on the spacecraft.

 Ron Baalke                       |    [e-mail]
 Jet Propulsion Lab  M/S 301-355  |    [e-mail]
 4800 Oak Grove Dr.               |
 Pasadena, CA 91109               |

------------------------------

Date: 18 Mar 90 20:13:40 GMT
From: att!tsdiag!ka2qhd![e-mail]  (John Magliacane)
Subject: UoSAT-OSCAR-14 & UoSAT-OSCAR-15 Status Report  15-Mar-90



UOSAT-OSCAR-14 and UOSAT-OSCAR-15 REPORT #007 15-Mar-90

** UoSAT-OSCAR-14 **

Attitude Control and Stabilization

Manueuvers prior to gravity gradient stabilization have taken somewhat longer
than expected.  The most recent delays were caused by the need to add digital
filters to the attitude determination software to remove unwanted noise from
the magnetometer readings.  The filters have been installed, and a new version
of the FORTH diary will be uploaded soon.

High Speed Downlink Tests

The UoSAT Command Station has been conducting limited experiments with the
9600 bits/second Frequency Shift Keyed (FSK) downlink on UO-14.  These tests
have been quite successful, doubling the highest digital link speed previously
used on any OSCAR satellite (4800 bps is routinely used on UO-11).

Data transmitted during these tests has been either asynchronous telemetry
from the Very Large Scale Integrated telemetry system or continuous streams of
1 bits (no data at all).  The "stuck ones" tests are very useful because of
the scramblers in the modulator and demodulator.  The 1's are scrambled and
transmitted as pseudorandom data over the RF link.  The groundstation
demodulators then lock onto this data, descramble it, and reproduce the
continuous 1's.  Any 0's in the demodulated output data stream are caused by
bit errors on the communication link, and the link bit error rate (BER) can be
calculated from the frequency of such transitions.

BER tests are to be scheduled into the DIARY in aid of those trying to test
their FSK receive system.  The first scheduled tests were scheduled for the
morning passes over the East Coast of the US on 15 March.

- de G0/K8KA.

** UoSAT-OSCAR-15 **

The team at Stanford has succeeded in detecting local oscillator (LO) leakage
from the UO-15 command receiver.  The weak signals were first detected on
March 10 and then again on March 11.  Roy Long, leading the Stanford Research
Institute team on the recovery attempt, said that there is no dbt that the
signal comes from UoSAT-15.  It is weaker than the corresponding signal on
UoSAT-14, as expected from prelaunch measurements.

Each UoSAT carries three receivers: a fixed-frequency command receiver and two
communications receivers with switchable frequency.  Efforts will now concen-
trate on monitoring one of the switchable frequency receivers.  If one of
these receivers is heard, commands will then be sent to change the receiver
frequency, which should cause a corresponding change in the LO frequency.
Observation of changed LO frequency will confirm that the satellite's
command system is basically healthy.

The work at Stanford is very time consuming, requiring azimuth and elevation
control of the huge Stanford 150 diameter dish to within tight limits.  Data
are collected for only a few seconds, followed by hours of post-processing.

--
AMPR : KD2BD @ NN2Z (Neptune, NJ)
UUCP : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd
       "For every problem, there is one solution which is simple,
       neat and wrong." -- H.L. Mencken

------------------------------

Date: 19 Mar 90 14:02:21 GMT
From: unmvax!nmtsun![e-mail]  (Daniel Briggs)
Subject: Re: Resolving Power of Hubble Space Telescope

In article <[e-mail]> bedding@extro (Tim Bedding) writes:
>Try an article by M. Mueller and G. Weigelt in Astronomy and Astrophysics
>(Vol. 175, p. 312, 1987) called "High-resolution astronomical imaging
>by roll deconvolution of Space Telescope data".

Thanks for the pointer, Tim.  I dug out the article, and it cleared
several points up.  I don't really have time to do a complete summary
from the ground up, but the basic idea is really pretty simple if you
know Fourier theory.  It also pointed out to me a few of the
prejudices that I carry regarding imaging problems.  A couple of the
off-the-cuff assumptions I made earlier really don't translate into
the optical domain so well.  Here are a few not terrible coherent
thoughts on the topic:

1) I asked why the HST people didn't do a "generic" CLEAN algorithm, as I
am used to in radio work.  The most important reason why not, is that the
PSF of a non-diffraction limited telescope (i.e. one limited by imperfections
in the optics, or by the instantaineous atmosphere), is *not* sharply peaked.
The speckle pattern is just that, a modest number of blobby shapes that may
all have roughly the same amplitude.  [If anyone is wondering, the PSF is
the image that you see when you look at a perfect point source.  Consider
that an extended astronomical object such as a galaxy is really made up of
a whole lot of point sources right next to each other.  Now take every one
of these point sources, multiply them by the aforementioned arbitrarily
blobby shape, and sum them all together.  This is the mess that a deconvolution
algorithm is trying to sort out.]  The generic CLEANs depend on being able
to tell which part of an image is real, and fix the pixels in descending order
of brightness.  If an intermediate brightness pixel was really just an artifact
from a bright one, by the time the algorithm gets around to trying to fix it,
the artifact has already been removed and is never confused with a real source.
This idea is absolutely dependent on having a strongly peaked PSF, so that
you know which pixel to start with.  In the radio (aperture synthesis) case,
we are trying to remove the sidelobes of the beam (PSF) caused by the fact
that our telescope is mostly empty space.  In the case of a filled aperture
telescope, the side lobes of the PSF are small enough that they aren't a
major worry.  What is a worry is imperfections in the reflecting surface.
Radio people deal with the analagous problems by a process know as
self-calibration.  Optical people use an image deconvolution algorithm such
as this roll-deconvolution.  I guess that the moral of the story is that
while we use very similar tools in our image deconvolution tasks, they are
actually used in slightly different places in the data paths.

2) As to what the roll deconvolution algorith actually is, I'm afraid that
I may have to drop into jargon a bit.  Basically, they are just using simple
inverse filtering to do the deconvolution for each image and point spread
function.  (The PSF is in fact a measured quantity, and may even be obtainable
from a foreground star on the same frame as the program object.)  The two
images are used to resolve the zero problem with the inverse filter.

For this kind of process, note the following relationships

  i1(x,y) = o(x,y) * p1(x,y)     and    i2(x,y) = o(x,y) * p2(x,y)

where i1 & i2 are the two images, o is the object in question, and p1 & p2 are
the PSF of the Hubble telescope in the two different orientations.  '*' is
convolution, of course.  Take Fourier transforms of these two, and get

  I1(u,v) = O1(u,v) x P1(u,v)    and    I2(u,v) = O2(u,v) x P2(u,v)

O1 & O2 are not really different functions here, but are the same function
that has been _measured_ in two different ways.  All we want to do is get
a good estimate of O, and we are done.  The "zero problem" mentioned before
is that where P1 and P2 happen to be zero, we have no information about O.
This is because Oi(u,v) = Ii(u,v) / Pi(u,v).  (We can't divide by zero)
By rolling the telescope around, we move the zeros of P around.  It turns out
to be very unlikely that the zeros of the two transformed PSFs happen to
coincide.  (In that case, you can apply a fixup by interpolation.)  The
simple idea behind this is to just toss out your measurement of O when the
tranformed PSF drops below some critical value.  You will still have a good
measured value from the other image.  When both measurements are OK, just
take the average of the two.  (Frankly, I don't see why they don't weight
each inversely with the magnitude of the transformed PSF, but that's a
fairly minor quibble.)  Once you have O, back transform to o, and you're done.
The authors go through a few variations about different ways to measure the
PSFs, but they all seem to work pretty well.  The simulated images do indeed
look pretty good.

-----
This is a shared guest account, please send replies to
[e-mail] (Internet)
Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801  (U.S. Snail)

------------------------------

Date: 19 Mar 90 16:29:01 GMT
From: clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!watserv1!watdragon!dahlia![e-mail]  (Murray S. Kucherawy)
Subject: Re: Challenger Report question

[e-mail] ("Mike Hewett") writes:
>If you haven't done it yet, I highly recommend reading the report.

Anyone know if it's FTP-able, and from where?

Please answer by e-mail.

=========================== Murray S. Kucherawy ============================
E-Mail:    mskucherawy@{ watmath | dahlia | crocus | trillium }.waterloo.edu
University of Waterloo, 1B Mathematics (entering Pure Math/Computer Science)
Postmaster/Gamesmaster, UW Computer Science Club ([e-mail])
System Manager,  VAX/VMS Network,  Board of Education, London, Ontario, Can.

------------------------------

End of SPACE Digest V11 #168
*******************